站在哪裡往前走

昨天我們確認了就業市場的徵才概況。今天要處理一個很多人心裡的疑問：這些事，不是資料科學家、DevOps、後端本來就在做的嗎？為什麼要多兩個職務？

這個問題很好，而且答錯的代價很實際——它決定了您面試時該強調什麼、進團隊後該對齊誰、以及出事時該誰負責。

今天要解決的問題

一個真實的失敗案例，您可能經歷過：

模型上線後準確率下滑。開會時，資料科學家說「我的模型在測試集上是好的，是資料變了」；資料工程師說「我照規格把資料送過去了，規格沒改」；後端說「我只是照 API 文件呼叫，回傳什麼我不知道」；SRE 說「我的服務可用性 99.95%，沒有異常」。

每個人都是對的，而模型卻還是壞的。

這就是責任界面沒定義清楚的代價：每個人都對自己的產出負責，但沒有人對「模型的線上效果」負責。

📊 職缺訊號

「需求分析與系統架構」出現在 15.0% 的生成式 AI 職缺、「治理、安全與權限」出現在 13.8% 的 MLOps 職缺——這兩項比例都不高，卻是資深職與初階職最明顯的分水嶺。原因可以推測為：初階做被分配的任務，資深定義誰做什麼任務。

一、現象：兩個職務的技能重心，重疊在哪、分岔在哪

先用一張圖看兩個職務的形狀：

圖 3-1：兩職務的技能重心（依 2026-07-25 職缺任務訊號比例換算為 0–5 分的示意圖）。重疊處是兩條路都要的，分岔處是你要選的。

用圖可以比較清楚的呈現：「部署與推論服務」「評測與安全」是兩者都有一定份量的重疊區，而「平臺與基礎設施」對 MLOps、「檢索與知識庫／代理與工具串接」對生成式 AI 應用，則是各自的主場。

這張圖也解釋為什麼「LLMOps」這個交會地帶最缺人——它需要同時具備兩邊各自的主場能力，而多數人只練了一邊。

二、原理：用「工作產出」而非「技術」劃界線

劃分責任最常見的錯誤，是用技術劃線：「會 Python 的是資料科學家、會 K8s 的是 MLOps」。這行不通，因為技術會重疊。

正確的方法是用工作產出（deliverable）與最終責任（accountability）劃線。同樣一件事，問「誰的名字要簽在上面」：

A＝最終負責（Accountable，只能有一個）、C＝共同參與（Consulted）、I＝需被告知（Informed）、–＝不涉及

兩個關鍵觀察：

1. 「模型線上效果」這一列，A 落在兩個新職務身上。 這正是它們存在的理由——傳統角色分工中，這一格是空的。
2. MLOps 工程師與 DevOps／SRE 的差別，不在會不會 K8s，而在「模型」這個字。 SRE 對「服務可用性」負責（服務有沒有回應），MLOps 對「模型有效性」負責（回應對不對）。服務 200 OK 但模型全預測成同一類，SRE 的儀表板是綠的，MLOps 的應該是紅的。

把這張 RACI 對回昨天的價值鏈圖，會更清楚：兩個新職務不是插進既有分工的縫隙，而是接管了整條鏈上「模型行為」這一維——上游的資料品質、下游的系統可用性各有其主，但「模型在線上表現如何」這件事，過去沒有主人。

圖 3-2：把 RACI 對回價值鏈（依職缺任務訊號整理的示意架構）。上排各格的 A 屬 MLOps／LLMOps 工程師，下排屬生成式 AI 應用工程師，中間黃色交會帶則是兩人必須共同維護、且最常沒人負責的地方。

三、動手：用三個問題定位任何一個模糊任務

實務上您會遇到大量灰色地帶。用這三個問題依序判斷，可以解決九成爭議：

問題 1：這件事做壞了，最先被業務單位罵的是誰？
        → 那個人就是 A（最終負責者）。

問題 2：這件事需要的關鍵知識，是「模型/資料的行為」還是「系統的行為」？
        → 模型/資料 → 偏兩個 AI 職務
        → 系統     → 偏 DevOps/SRE/後端

問題 3：這件事的產出物是什麼？誰交付、誰驗收？
        → 交付者是 A，驗收者是 C。講不出產出物 = 這件事還沒被定義清楚，
          先別分工，先定義。

舉例實測——「向量資料庫掛了誰處理？」

• 問題 1：使用者問不到東西 → 生成式 AI 應用工程師先被找。
• 問題 2：如果是「服務起不來、磁碟滿了」→ 系統行為 → SRE／MLOps；如果是「服務正常但檢索結果爛掉」→ 資料行為 → 生成式 AI 應用工程師。
• 問題 3：產出物是「可用的檢索服務」與「檢索品質達標」——兩個不同的產出物，所以本來就該是兩個負責人。

這個例子說明了灰色地帶的本質：不是「誰該負責」講不清，而是大家在講不同的產出物。

四、取捨：小團隊怎麼辦？

現實是，台灣多數團隊沒有六種角色，可能只有兩三個人。這時候可以用優先順序配置。

💡 一人團隊的鐵律

如果你是團隊裡唯一的工程師，請記得：可以不做微調、不做自建平臺，但不能不做監控與評測。 前兩者的代價是「做得慢」，後兩者的代價是「壞掉了不知道」——後者對專案影響是比較嚴重的。

今日小結

• 責任要用工作產出與最終責任劃分，不要用技術劃分——技術一定會重疊。
• 兩個新職務存在的理由，是傳統分工中「模型線上效果」這一格沒有人簽名。
• MLOps 與 SRE 的分野在於：SRE 對「服務有沒有回應」負責，MLOps 對「回應對不對」負責。
• 灰色地帶用三個問題判斷（誰先被罵／是模型還是系統的知識／產出物是什麼），多數爭議其實是「大家在講不同的產出物」。
• 小團隊不是不分工，是排優先序：監控與評測永遠不能砍。

明天預告

明天是第一部曲的收尾：把任務訊號轉成一張你能照著走的學習地圖。文章將提供三條主流轉職路線（後端／DevOps、資料科學、前後端應用）各自的既有優勢與待補缺口，以及這 30 天該怎麼取用——包括「只有週末有空」的讀者版本。